On the Evolution of .NET Technical Documentation and Naming Conventions

This article is not about technology; it is simply about two things that happened a long time ago, but which I only discovered a few months ago.

The Disappearance of the MSDN Platform

In the past, .NET technical documentation was primarily centralized on MSDN (Microsoft Developer Network), a platform that provided developers with API references, tutorials, and sample code.

In my notes from a few months ago, I can still see myself using "MSDN" to refer to .NET documentation. It was only a few months ago that I noticed the MSDN website no longer uses the term msdn. After looking into it, I discovered that MSDN has been retired, its content migrated to Microsoft Docs, and the platform has since been rebranded as Microsoft Learn.

The articles "MSDN Code Gallery has been retired" and "Updating the MSDN and TechNet migration to docs.microsoft.com" explain this transition. If you want to search for older versions of .NET documentation, you can find them in the ".NET Previous Versions" section. However, since the documentation update strategy is split between versions prior to .NET Framework 4 and the continuously updated latest versions, some older information may no longer be complete.

Changes in Field Naming Conventions

Around June, when my company was discussing naming conventions, I mentioned that there was no current standard requiring the _ prefix for fields. I was immediately corrected; the current Microsoft documentation on "C# Identifier naming rules and conventions" states:

Private instance fields start with an underscore (_) and the rest of the text is camelCased.

After thinking about it, I realized that in official examples from the last two years, private fields have indeed started using the _ prefix.

I did some digging, and I have to say, early .NET documentation is becoming increasingly difficult to find. It took a long time to locate this "Internal Coding Guidelines" post:

Do not use a prefix for member variables (, m, s_, etc.). If you want to distinguish between local and member variables you should use “this.” in C# and “Me.” in VB.NET.

But why has it changed to using the _ prefix for everything now? According to the guidelines proposed by .NET Core in 2016, ".NET CoreFX - C# Coding Style":

We use camelCase for internal and private fields and use readonly where possible. Prefix instance fields with , static fields with s and thread static fields with t. When used on static fields, readonly should come after static (i.e. static readonly not readonly static).

This is the exact opposite of the early .NET Framework naming conventions. At the time, using prefixes for private fields was discouraged. However, the .NET CoreFX team believed this naming style was easier to maintain. Consequently, with the merger of .NET Core and .NET Framework, .NET 5 unified these style guides and gradually promoted the convention of using the _ prefix for private fields across all examples.

Now, the .NET source code and many open-source projects follow this naming convention. I feel like I've stepped into a parallel universe, as my understanding until this year was still stuck on the version without prefixes XD. Compared to the early .NET Framework era, the code style of modern .NET Core is much more unified. If you are interested, you can check the Reference Source; the private fields there are a chaotic mix of no prefix, _ prefix, and m_ prefix.

Revision History

• 2024-09-20 Initial document creation.